Fix layout-direction staircase, resource-bar test drift, and pinned test-mode issues#166
Open
Krathe82 wants to merge 7 commits into
Open
Fix layout-direction staircase, resource-bar test drift, and pinned test-mode issues#166Krathe82 wants to merge 7 commits into
Krathe82 wants to merge 7 commits into
Conversation
The test render (UpdateTestPowerBar) kept its own copy of the resource-bar layout math, which drifted from the live ApplyResourceBarLayout — most visibly the bar rendering full width over the frame border in test mode because the test copy lacked the border-inset subtraction. Extract the shared geometry/appearance (texture, orientation/fill, size incl. border inset, anchor, frame level, background, border) into DF:LayoutResourceBar(frame, db). Both the live apply and the test render now call it and keep only their own value + fill colour (real UnitPower vs mock testData), so the two can no longer drift. Also fixes a latent anchor-default mismatch (test defaulted "BOTTOM", live "CENTER").
…t layout SecureGroupHeader_Update re-anchors displayed children with SetPoint but never ClearAllPoints-es them first, so flipping the growth point (Horizontal LEFT -> Vertical TOP) leaves each child anchored by both the old and new point and they cascade diagonally (the "staircase"). The pinned/flat-raid ApplyLayoutSettings set the new layout attributes before clearing the old child points; clear them first, matching the proven DF:UpdateRaidHeaderLayoutAttributes path. Also defer pinned layout changes attempted in combat: ApplyLayoutSettings silently dropped them (bare return) instead of queuing for PLAYER_REGEN_ENABLED, so a Direction/spacing/size tweak made mid-combat never reached the live header until the next settings poke or a /reload. Mirrors FlatRaidFrames.pendingLayoutUpdate.
Several pinned-test-mode rendering fixes: - GetTestUnitData party branch returned nil past the 5 hand-authored party scenarios. Main party frames are 0-based; pinned PLAYER frames are 1-based, so index+1 overran the table by one and blanked the last frame. Wrap the lookup so every party-mode frame maps to a distinct scenario. - Cap party player pinned sets at 5 frames (a party can't exceed 5) at the slider and the three runtime call sites; raid stays 40, boss stays 8. - AFK countdown froze on pinned test frames: the 1s AFK timer ticker iterated the main party/raid test pools but not the pinned test pools. Add a pinned pass mirroring the main blocks. - Animation ticker only updated pinned sets 1-2 (hardcoded); use MAX_SETS.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A handful of pre-existing robustness fixes, all found while testing the pinned-frames work. None depends on the others; grouped into one PR because they share
PinnedFrames.lua/TestMode.luaand would otherwise conflict across PRs.Pinned & raid frames: orientation "staircase"
Switching a pinned (or flat-raid) set's grow direction between Horizontal and Vertical left the frames cascading diagonally on top of each other until a
/reload.Root cause is in Blizzard's
SecureGroupHeader_Update(Blizzard_RestrictedAddOnEnvironment/SecureGroupHeaders.lua): it re-anchors each displayed child withSetPointbut neverClearAllPoints-es them first. So when the growpointflips (LEFT↔TOP), each child keeps its old anchor and gains the new one — the diagonal staircase.ApplyLayoutSettingswas setting the new layout attributes before clearing the old child points; this clears them first, matching the existingDF:UpdateRaidHeaderLayoutAttributespath.Also: pinned layout changes (direction / spacing / size) attempted in combat were silently dropped (a bare
return) instead of being queued forPLAYER_REGEN_ENABLED, so they never reached the live header until the next change or a/reload. Now deferred and replayed on combat end, mirroringFlatRaidFrames.pendingLayoutUpdate.Resource bar: live/test geometry drift
UpdateTestPowerBarcarried its own copy of the resource-bar layout math, which had drifted from the liveApplyResourceBarLayout— most visibly the bar rendering full-width over the frame border in test mode (it lacked the border-inset subtraction). Extracted the shared geometry intoDF:LayoutResourceBar(frame, db); both paths now call it and keep only their own value + fill colour, so they can't drift again. Also fixes a latent anchor-default mismatch (test"BOTTOM"vs live"CENTER").Pinned test-mode preview
nilpast the 5 hand-authored party scenarios; pinned player frames are 1-based vs the main party's 0-based, so the lookup overran by one and blanked the last frame. The lookup now wraps the 5-entry table, and party player sets are capped at 5 (a party can't exceed 5; raid stays 40, boss 8).MAX_SETS.Not verified with
luac(none available); validated by in-game/reload.